home *** CD-ROM | disk | FTP | other *** search
/ AOL File Library: 12,000 to 12,999 / 12000.zip / AOLDLs / Tech Notes & Information / Overview of Flow Control / FLWCNT.txt next >
Encoding:
Text File  |  2014-12-24  |  10.8 KB  |  192 lines
  1. FLOW CONTROL
  2. Last update: 28 Oct 1994
  3.  
  4. Q: What is flow control?
  5.  
  6. A: Let's start by saying the Flow Control (FC) is necessary because the 
  7. port speed (DTE-DCE), or computer to modem) is frequently higher than the 
  8. carrier speed (DCE-DCE, or modem to modem) when using a high-speed, 
  9. data-compressing modem.  In these types of connections, the user sets the 
  10. computer to feed the modem data at 57600 or 19200 bps, but the data leaves 
  11. the modem at only 9600 or 2400 on the phone wire.  Data accumulates in the 
  12. modem, and when it's memory is full, it has to say STOP or corrupt the 
  13. data.  The communications program sees this signal, and stops until told 
  14. it's ok to resume.  That, in a nutshell, is flow control..
  15.  
  16. Or, the comm program may be writing to disk and wants to tell the modem STOP 
  17. for a minute. This  communication between the modem and the software is flow 
  18. control. It may even come from the other computer.  For example, if your 
  19. comm program says STOP, your modem stops.  It then has to tell the other 
  20. modem to stop because it obviously can't hold an infinite amount of data.  
  21. V.42 error control provides that mechanism between modems.  The other modem 
  22. has to tell the host program to stop.   So, flow control is very important.
  23.  
  24. Q: What types of flow control are possible?
  25.  
  26. A: There are three different forms of "flow control":
  27.  1) end-to-end
  28.  2) modem-to-modem
  29.  3) local
  30.  
  31. Only the third one can be handled by RTS/CTS which are signals on the RS232 
  32. interface between the modem and the local computer.
  33.  
  34. Any form of flow control which exists across the telephone line MUST be 
  35. 'in-band.' That is, it must be part of the data flow and detected as being 
  36. 'something special.' This is how XON/XOFF works. These special characters 
  37. are inserted into the data stream and the application at each end will see 
  38. these and respond to them.
  39.  
  40. The modem to modem flow control is handled by the error control protocol 
  41. and it too is done with 'special characters' or a group of special 
  42. characters which are embedded into the the data stream.
  43.  
  44. Any software application where the error control (and buffering) functions 
  45. are being used by the local modem will require local flow control. The 
  46. cable, the software application, and the modem initialization must all be 
  47. set to do the same thing. The default on the high-speed modems from PPI 
  48. will be for hardware flow control. (&K3).
  49.  
  50. Q: What do RTS/CTS and XON/XOFF flow control stand for? Which is preferable, 
  51. hardware or software handshaking flow control?
  52.  
  53. A: Hardware flow control is simply faster than XON/XOFF flow control and 
  54. does not add overhead to the computer's processing load. Hardware FC 
  55. wiggles voltages on the RTS and CTS wires (ReadyToSend, ClearToSend) in 
  56. the modem cable.  Even internal modems have modem cables, even if it is 
  57. very short lines on the modems printed circuit board.  The internal modem 
  58. has the 16550 uart chip, just like in a serial board for an external modem, 
  59. and these wires come out of the UART chip.   Voltage variations are
  60. instantaneous.
  61.  
  62. Software flow control sends extra characters that are not instantaneous 
  63. as they require processing by the serial device.  A user  may be familiar 
  64. with using XON/XOFF manually.  There are several names for the XON/XOFF 
  65. flow control characters:
  66.  
  67.  hex 13   decimal 19   DC3   XOFF   CTRL-S   Stop sending,   Xmission Off
  68.  hex 11   decimal 17   DC1   XON    CTRL-Q   Resume sending, Xmission On
  69.  
  70. "Xmission" is equivalent to "Transmission" in this description. The ASCII 
  71. specifications call these control chars DC1 and DC3 (Device Control). Back 
  72. when digital data was stored on audio cassettes, computer operators used 
  73. these characters to start and stop the tape drives (devices).
  74.  
  75. If one is using an ASCII terminal emulator (regular old communications 
  76. program like Procomm) to read CIS messages, one can manually use CTRL-S 
  77. to stop the scrolling of ASCII messages (so the data can read them before 
  78. they scroll off the screen, for example), and CTRL-Q to resume.   
  79. Essentially, the action is flow control.  If one is using &K3 and Hardware 
  80. local  flow control ("local" describing the computer to modem connection, 
  81. as opposed to between the modems themselves), these CTRL characters simply 
  82. pass through the modem as data, and the host sees them and stops (if the 
  83. host is set up to recognize flow control, while flow control on the modem 
  84. itself is disabled).  If  one is using &K4, and XON/XOFF local flow control, 
  85. the modem will see the flow control characters and stop, informing the other 
  86. modem, which informs the host. The host, having been instructed to stop, 
  87. stops.
  88.  
  89. With XON/XOFF flow control, the modem or comm driver probably has a few 
  90. hundred characters buffered up when it wants to report busy, and there is 
  91. the problem of getting the XOFF character to the top of the queue.  Also, a 
  92. 16550 UART in the serial I/O controller card might already have 16 
  93. characters in it, and your XOFF has to get in line and wait. Plus, these 
  94. characters are additional overhead, additional characters you must send, and 
  95. they take time to send a bit at a time.
  96.  
  97. Hardware is instantaneous and adds no overhead, but requires a modem cable 
  98. with a couple more wires in it.  It is called "out of band" signaling, 
  99. because it is done via other means outside the data channel.
  100.  
  101. Q: Speaking of UARTs, how does the UART figure into flow control?
  102.  
  103. A: In a RTS/CTS flow control situation, when the computer drops RTS, the 
  104. modem can stop sending the computer data as soon as it finishes outpulsing 
  105. the current character; but if the computer sends an XOFF to the modem, the 
  106. XOFF would go into the UART's buffer (and if the 16550 FIFO gets loaded up, 
  107. all preceeding characters in the Transmit FIFO have to be sent first before 
  108. the UART even starts to outpulse the Xoff), then the UART has to outpulse 
  109. the XOFF and the modem receive the entire XOFF character before it can 
  110. recognize it as an XOFF and stop sending the computer data as soon as the 
  111. modem finishes the character it is currntly sending to the computer.
  112.  
  113. Likewise, in the other direction, when the modem drops CTS, the 
  114. communications program can stop stuffing the UART's Transmit Buffer 
  115. immediately, but what is in the UART's Transmit Buffer (and, for the 16550, 
  116. in the Transmit FIFO) will still be sent to the modem anyway. (That is why, 
  117. when RTS/CTS flow control is used, the modem will drop CTS when its buffer 
  118. is _nearly_ full, not when the buffer is completely full--the communications 
  119. program has no decent way of flushing the 16550 Transmit FIFO so the modem 
  120. could still receive 16 bytes after the modem drops CTS.) But with XON/XOFF 
  121. flow control, when the modem sends the comptuer an XOFF, it has to be 
  122. outpulsed, stuffed in the UART's Receive Buffer (and for the 16550, the 
  123. Receive FIFO, which can hold 16 bytes), and it is possible that the  
  124. communications program won't even grab data from the Receive FIFO buffer 
  125. until another 3, 7, or 13 characters are received, and then there are still 
  126. possibly 16 characters in the 16550's Transmit FIFO buffer when it does 
  127. finally act on the XOFF, so up to 30 or so characters could be sent to 
  128. the modem from the time the modem had sent the XOFF until the time data 
  129. flow actually stops.
  130.  
  131. Q: Does the speed of RTS/CTS vs. XON/XOFF matter?  Is XON/XOFF more reliable?
  132.  
  133. A: The overall speed gain of RTS/CTS vs XON/XOFF may not make a major impact 
  134. on transfer results; furthermore, exact differences depend largely on the 
  135. processor speed of the computer, the attached UART, and a number of local 
  136. factors. Is XON/OFF more reliable? Not as long as the XON and XOFF 
  137. characters are strictly between the computer and its attached modem. 
  138. However, if an XON or especially an XOFF comes from some source other than 
  139. local flow control, there can be problems. For example, line noise that 
  140. just happens to "look like" an XOFF (Ctrl-S) will "freeze" the 
  141. communications session. (That is why if one is using XON/XOFF flow control, 
  142. one should use a modem<->modem error correction protocol if possible. Has 
  143. anyone wondered why there are occasional freezes when using &Q0&K4 or 
  144. &Q6&K4? Or a file transfer protocol that assumes 8-bit transparency 
  145. will usually have problems with binary files or transmitting block #19 
  146. (ASCII 19 = Ctrl-S = XOFF). Fortunately, both Z-modem and CompuServe-B+ 
  147. transfer protocols will "quote" XON and XOFF (i.e., substitute other 
  148. codes so an ASCII 19 or ASCII 17 is not actually transmitted) so Z-modem 
  149. and CompuServe-B+ can be used even when using XON/XOFF local flow control.
  150.  
  151. But those who try Xmodem, 1K-Xmodem, Ymodem, 1K-Xmodem-g, or Ymodem-g 
  152. when using local Xon/Xoff flow control are in for a different story entirely.
  153.  
  154. Q: Does selection of file transfer protocol affect flow control?
  155.  
  156. A: No, the file transfer protocol (X-, Y-, Z-modem or CIS B+) does not 
  157. affect the choice of flow control, but it can indirectly make it less 
  158. important.  X- and Y-modem and CIS B+ sends one data block (or two for 
  159. WinCIM B+) and then will wait until the ACK (acknowledgement) from the 
  160. receiver is sent back before sending the next data.  That slows flow 
  161. greatly, and makes flow control far less important.  The modem empties, and 
  162. only then is the ACK received back from the other end and only then is more 
  163. data sent.  But it is not the same thing as flow control.
  164.  
  165. Z-modem and Y-modem-G are extremely dependent on proper flow control, the 
  166. protocols won't work otherwise.  These protocols dont send ACKS, the sender 
  167. simply starts pumping data out as fast as possible.  If an error is detected, 
  168. the receiver sends a NAK (negative acknowledgment) if Z-modem or aborts if 
  169. Y-modem-G, but otherwise there is no stopping.  Flow control becomes 
  170. extremely important at that point.  Because of this, Z-Modem and Y-Modem-G 
  171. are the fastest protocols.  Proper flow control is most important during 
  172. uploading.  When downloading, if the communications program can keep up, 
  173. flow control is rarely exercised.
  174.  
  175. Q: I set up flow control in my software. Do I have to configure my modem 
  176. for it?
  177.  
  178. A: The modem flow control and the software flow control must match because 
  179. it is a communication between them.  If using &K4, for example, one must 
  180. set the software to XON/XOFF flow control.  In the case of WinCIM, that's 
  181. set in the Windows Control Panel. If &K4 is not used, &F includes the 
  182. default &K3, and the software should also be set to Hardware.
  183.  
  184. If flow control is set wrong, the modem and the software cannot 
  185. communicate.  The modem will cry STOP, and no one will hear (in cyberspace, 
  186. no one can hear a modem screaming <g>).  Characters are lost because the 
  187. modem simply can't store any more.  Typically, instead of losing a random 
  188. character now and then like a UART overrun,  big blocks of characters are 
  189. lost, several hundred perhaps.
  190.  
  191.  
  192.